1. Field
The present invention relates to a method and apparatus for porting source code. Porting is the process of adapting software (such as application software or libraries) so that an executable program or other user-ready software product can be created for a computing context that is different from the one for which it was originally designed. Thus software may be ported to a different platform (hardware architecture and set up), a different system (which is used herein to refer to the platform plus the operating system), or a different run time environment (which is used herein to include the platform and system, compilers, library and other settings in the user environment).
2. Description of the Related Art
Software can be referred to as portable when it runs on a wide variety of different computing environments or when the cost of porting it to a new environment is less than the cost of writing it from scratch. The lower the cost of porting software, relative to its implementation cost, the more portable that software is said to be.
The invention is primarily targeted at High Performance Computing (HPC) applications, libraries and tools where it is common to port the code to a wide range of supercomputing platforms which have differing architectures and software stacks forming the tool chain of programming tools (compiler, parallel libraries etc.) used to create the executable program or other product. However, it is also more widely applicable, for example in porting applications from other fields and to other platforms
Some areas where the invention is valuable are in the porting of applications to new low-power and bespoke supercomputing systems that are becoming available. These systems are built from low-power processors (e.g. ARM), many-core processors (for example Intel's MIC architecture) or processors specifically designed for the HPC market (Fujitsu's SPARC64 IXfx). Porting applications to these platforms is a big challenge for those coming from the commodity x86-based family of systems.
FIG. 1 illustrates the steps required when porting an application, library or other piece of software to a new architecture; possibly with a different set of compilers, parallel programming libraries (such as the MPI library) or other system-specific tools. In this context, the term library may be taken to include a collection of implementations of behavior with a well-defined interface by which the behaviour is invoked.
In step P10 the source code is obtained and in step P20 it is unpacked and subsequently in step P30 prepared for compilation. Step P40 compiles the code and then if there are compile errors these are fixed in step P50 and the code is compiled again. Otherwise, if there are no compilation errors, quality assurance (QA) testing takes place in step P60 and if the tests are passed the code is packaged in step P70, installed in step P80 and documented in step P90.
If the QA tests are failed then there is debugging in step P100 which leads to further preparation for compilation in step P30.
From this explanation, we see that there is an iterative step during the compilation stage. Note that the ‘compile’ stage here represents all the (build) steps for a piece of software to be considered ready for QA testing and installation—e.g. compiling and packaging of object files for libraries or compiling and linking for applications. If any errors occur at this point it is necessary to branch off from the normal porting flow and fix these errors.
FIG. 2 shows in more detail the iterative process involved in fixing compile-time errors. When errors occur, usually a descriptive error message is output from the compiler. The user, application developer or system administrator then (manually) analyses these errors to identify the type of fix required in order to solve them. Examples of errors that may occur include an incorrect or missing compiler option, an incompatibility in the source code due to non-standard code or incorrect pre-processor directives or dependent libraries and utilities that are missing. Once a fix for the error is applied the code is recompiled. Further iterations of the process take place if another compile-time error occurs.
The steps P20 to P60 already described with respect to FIG. 1 are shown along with an expansion of step P50 for fixing the compiled-time error. The errors are analyzed in step P51 and according to the type of fix are fixed in step P52, P53 or P54 for example.
Step P53 provides a fix for a missing library or other utility, step P53 may be an incorrect or missing compiler option and step P54 is an incompatibility in the source code which requires a source code “patch” or modification.
Currently the process described above is primarily a manual one, requiring substantial time and effort from the person porting the code or from the system development team depending on the nature of the errors. Some tools exist which can help in the porting effort, for example Lint which flags suspicious and non-portable code constructs; the Intel Static Security Analysis tool which finds porting and security errors and the Bauhaus project which detects cloned and dead source code. A number of technical reports, websites and blogs are also available on how to port to a particular architecture. However, these solutions automate only one particular area or are offline guides which still require extensive work on the part of the individual porting the software.
It is thus desirable to provide a tool which automates the correction of build errors during software porting.